18-1 取长补短：巧用搜索工具+AI完成项目调研与开发
到本章为止，课程的基础知识已经全部讲完。从这一章开始进入"活学活用"阶段：不再教新工具的基础用法，而是讲怎么把前面学过的搜索工具、AI 会话、Skill 组合起来，解决真实项目里的完整问题。本节解决第一个问题：为什么"把需求直接丢给 AI"产出的东西和你预期的差得很远，以及怎么用"搜索工具 + 多轮会话"把需求变成 AI 能正确执行的东西。
一个真实案例：两天的活，以前要干一个月
先看 Brian 的一个真实项目：一个 AI 方向的演示系统，要覆盖从数据集到训练到应用的完整链路，界面上包含系统管理、角色管理、用户管理、菜单管理等一整套后台页面——而且都是可用的功能，不是假数据。
- 以前的做法：3~4 个人干一个月；加班加点压到两个星期，但还是会留下一堆 bug。
- AI 时代的做法：两天完成。
两天是怎么来的？第一步他做了什么——把需求丢给模型："我要干一个全链路的东西"，然后让 AI 去干。结果：AI 干出来的东西和预期差得非常远。
为什么会差得远？因为那句话需求里：
- 没有对样式提要求——AI 只能按自己的默认审美来；
- 没有对技术栈提要求——AI 会随机选一套它熟悉的方案；
- 没有对训练链路和环节提要求——"全链路"三个字覆盖不了识别、审核、训练、激活这些具体环节。
这就是本节的核心矛盾：AI 的产出上限，取决于你输入的下限。 而把输入从一句话变成一份可执行的方案，靠的就是两件前面章节讲过、但很多人没真正用起来的工具。
破局两件套：搜索工具 + 多轮会话
第一件：用搜索工具突破自己的信息茧房
你想到的方案，大概率别人已经开源过更好的版本。GitHub 上有大量优质开源项目，这就是第一个搜索方向：搜同方向的开源项目，看别人的技术选型和项目结构。
Brian 的做法不是自己一个个去搜——他让 AI 去搜。AI 在 GitHub 上检索了这个方向的开源项目，下载到本地的 demos/ 目录，研究了这些项目的代码和技术栈，然后借鉴这些项目的技术栈来设计本项目的技术栈和项目结构。方案文档里后面的几个章节，就是 AI 自己调研之后补充进来的。
第二件：和模型多轮会话，把需求挖出来
需求不是一次说清楚的，是聊出来的。Brian 在描述需求的过程中持续和 AI 探讨，逐步补齐：
- 这个系统要的是全链路：从识别、审核、训练到激活；
- 除了平台本身，还需要一个文档站——而且是静态文档站（不需要交互），这个约束一给，AI 就会从大量静态站点方案里选型；
- 文档站里要嵌入图片；
- 交付顺序：先完成平台开发，再做文档站，再做图片嵌入流程的测试，最后是部署到云端机器。
这些探讨最终落地成一份方案文档。文档的演进过程值得注意：最初只有一节"项目背景"，后面的需求清单、数据资源现状、技术方案、里程碑，都是讨论过程中一点点扩展出来的。这个"方案文档从一节长成一份"的过程，就是需求挖掘的过程。
可复制的调研提示词骨架
把上面的过程抽象成一条可以直接用的提示词：
我要做一个【XX 方向】的演示系统。在动手写任何业务代码之前，先完成三件事：
1. 调研：在 GitHub 上搜索这个方向的优质开源项目（看 star 数、近期活跃度、
技术栈），把最有代表性的几个下载到 demos/ 目录，研究它们的技术选型和
项目结构，输出一份对比结论；
2. 方案：基于调研结果给我一份技术方案文档，包含：项目背景、需求清单、
数据资源现状、技术方案选型（说明借鉴了哪些项目、为什么）、开发里程碑；
3. 风格稿：先别写业务代码，用静态 HTML 出 2~3 版页面风格，我选定后再进入开发。
约束：前后端分离；工程化目录结构；附带运维脚本；说明项目资源和入口。
text
界面风格：三招取长补短
风格是"AI 默认产出"和"预期"之间差距最大的地方。Brian 用了三招，层层递进：
第一招：成熟 UI 组件库打底。 用 Ant Design、Element Plus 这类成熟组件库（按你的技术栈决定），整体风格会天然统一。这是最朴素也最有效的一招。
第二招：ui-ux-pro-max 这类设计 Skill。 前面章节（2-02 提过、仓库里已装）介绍过 ui-ux-pro-max——一个内置 50+ 设计风格、21 套配色、多技术栈的 UI/UX 设计 Skill。安装后让它来形成页面，效果比裸奔好得多。但注意：用默认配置跑出来的效果还没那么好看，必须对具体细节提要求（配色倾向、密度、卡片圆角、留白节奏），才能形成统一的视觉语言。
第三招：先出几版静态 HTML，取长补短。 这是 Brian 在本项目里的实际做法：让 AI 先形成几套静态 HTML 风格稿；同时他去看其他项目的前端页面长什么样，把认为不错的视觉效果指给 AI——"取长补短，让 AI 把我们认为不错的视觉吸收进我们自己的项目"，最后再定稿进入开发。
人的价值在哪里
这套流程里 AI 干了调研、方案、编码的绝大部分工作，那人的作用是什么？Brian 总结为两条，也是全课程反复出现的主题：
- 让 AI 按我们指定的方向走——需求边界、交付顺序、风格约束都是人定的；
- 让 AI 按正确的技术方向走——前后端分离、合理的工程化目录、运维脚本、项目资源与入口，这些架构要求是人对 AI 提出来的。
这两条，没有编程经验的人是提不出来的。所以基础还是要打：底层编程知识决定了你能不能判断 AI 给的方案对不对、好不好。架构给对了，即使后面交给其他开发人员接手运维，这也是一套优质的项目结构。
有人会抬杠："以后哪还有人员运维，不全是交给 AI 吗？"这里要点破一个现实约束：现在的演示项目代码行数不多，AI 一次会话能装下整个项目；但当项目代码量大到一定程度，AI 每次会话都要携带大量上下文，改对的难度会陡增——这个问题怎么解，是 18-03 的主题（上下文压缩）。
朴素工具也一样能用
突破信息茧房不一定非要用课程里自建的搜索基建。DeepSeek、豆包这类产品自带深度思考 + 联网搜索，把你手头需求丢给它去梳理，同样能完成"调研 → 需求清单 → 方案"的链路。工具是拿来用的，不是拿来供的——课程自建的 local-search（详见 5-02，SearXNG + 爬虫引擎）胜在可控和可扩展，日常调研用现成产品完全够。
本节小结
- AI 时代程序员的先天优势：掌握前沿 AI 工具，一个人干以前一个团队的活。但 AI 干完活之后，你的价值转移到"定方向、定标准、判断对错"上。
- "一句话需求丢给 AI → 产出跑偏"的根因：没提样式、没提技术栈、没提链路环节。解法是搜索工具（开源项目调研）+ 多轮会话（需求挖掘）。
- 需求文档不是一次写成的：从一节"项目背景"开始，边讨论边长出需求清单、技术方案、里程碑；技术选型可以让 AI 下载开源项目到 demos/ 研究后借鉴。
- 风格三板斧：组件库打底 → ui-ux-pro-max 这类设计 Skill（要提细节要求）→ 静态 HTML 出几版取长补短。
- 项目变大后"每次会话携带大量上下文改不对"是新问题，引出下一节的上下文压缩与自成长循环。
↑